前言

系統上線不代表工作結束，今天要討論的是讓 RAG 系統能長期穩定運行、持續改進的監控與維運機制。

需要記錄哪些 Log？

一次完整的查詢，建議至少記錄：

def log_query(question, retrieved_chunks, answer, latency, user_id=None):
    log_entry = {
        "timestamp": get_timestamp(),
        "user_id": user_id,
        "question": question,
        "retrieved_chunk_ids": [c["id"] for c in retrieved_chunks],
        "retrieved_scores": [c.get("rerank_score") for c in retrieved_chunks],
        "answer": answer,
        "latency_ms": latency,
    }
    save_log(log_entry)

這些資訊之後可以用來：

• 分析哪些問題最常被問（找出使用者真正的需求）
• 找出檢索結果分數普遍偏低的問題類型（可能代表知識庫有缺口）
• 追蹤系統延遲的變化趨勢

使用者回饋機制

在前端介面加入簡單的回饋按鈕（例如「這個回答有幫助嗎？👍👎」），收集使用者對回答品質的直接反饋：

class FeedbackRequest(BaseModel):
    query_id: str
    is_helpful: bool
    comment: str = None

@app.post("/feedback")
def submit_feedback(request: FeedbackRequest):
    save_feedback(request.query_id, request.is_helpful, request.comment)

使用者標記「沒有幫助」的案例，是 Day 26 錯誤案例分析很珍貴的第一手資料來源——比起自己想測試案例，真實使用者回報的問題更貼近實際使用情境。

監控關鍵指標

建議建立一個簡單的儀表板（或至少定期產出報表），追蹤：

知識庫的持續維護

知識庫不是建一次就結束，建議建立：

1. 定期更新排程：搭配 Day 9 提到的增量更新 Pipeline，定期把新文件加入知識庫
2. 過時內容下架機制：確保不會用已經過時的資訊誤導使用者（可以用 Day 8 的 Metadata 標記文件的有效期限）
3. 知識庫缺口盤點：定期檢視「查無資料」的問題清單，判斷是否需要補充新的文件到知識庫中

異常告警

當系統出現異常時（例如錯誤率突然升高、延遲大幅增加、API 額度即將用盡），應該要有告警機制及時通知維運人員：

def check_health_metrics(metrics):
    if metrics["error_rate"] > 0.05:
        send_alert("錯誤率超過 5%，請檢查系統狀態")
    if metrics["avg_latency_ms"] > 5000:
        send_alert("平均延遲超過 5 秒，請檢查效能瓶頸")

小結

一個 RAG 系統的生命週期，不是「上線」就結束，而是透過持續的監控、使用者回饋、知識庫維護，讓系統隨著時間越來越貼合真實使用需求。明天是這個系列的最後一天，我們會做一次完整的回顧與總結。